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Abstract — ^NASA’s Earth Observing System (EOS) Ice, 
Cloud, and Land Elevation Satellite (ICESat) mission was 
one of the first missions under Goddard Space Flight 
Center’s (then-) new Rapid Spacecraft Development 
Office. This paper explores the lessons-leamed under the 
ICESat successful implementation and launch, focusing 
on four areas: Procurement, Management, Technical, and 
Launch and Early Operations. Each of these areas is 
explored in a practical perspective of communication, the 
viewpoint of the players, and the interactions among the 
organizations. Conclusions and lessons-leamed are 
summarized in the final section. 
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1. Background 

Goddard’s Rapid Spacecraft Development Office (RSDO) 
was conceived to shorten the amount of runway time 
needed for a spacecraft contract to get through the 
procurement cycle, and at the same time simplify the post- 
award management burden. The goal of the first RSDO 
contract (or Rapid /, which has since evolved into Rapid 
IT) was to competitively grant core contracts to a pool of 
qualified vendors for specific spacecraft (the catalog), and 
then quickly arrange match-ups (“Deliveiy Orders”) 
between catalog items and mission payloads. 


By the time of the formal kick-off for the ICESat mission 
in 1997 there had been almost 5,000 objects launched into 
orbit. After a campaign as extensive as that the aerospace 
industry had accrued a correspondingly massive 
infrastructure of established, traditional, tried-and-true 
procurement and management methods and standards. 
The RSDO concept challenged many of these methods 
and standards with the Catalog approach available for any 
Government mission. (Non-Government users can access 
RSDO as well if they can identify a Government rep- 
resentative to manage the contract). 

The following sections describe how well or ill the Rapid 
Spacecraft worked for ICESat. The lessons-leamed are 
discussed in the areas of procurement, management, 
technical, and launch and early operations. 

2. Procurement 

Even though it was only the second mission through the 
RSDO process, the procurement worked surprisingly well. 
There were no unusual rough spots or awkward points in 
the whole cycle - an indication Aat the preparatory RSDO 
work for the core contract had been particularly well 
thought-out. Communication between the contracting 
office and the project office, and between the contracting 
office and the Offerors was well facilitated under RSDO. 
Specific ICESat lessons-leamed are pointed out in the 
following sections for the procurement cycle, contract 
paperwork, team pre-conceptions, and of course, the 
unknowns. 

The success of the ICESat procurement was largely due to 
the expertise and dedication of the RSDO contracting 
officer, Ms. S. Collighon. The successful execution of the 
subsequent delivery order was dependent on the wisdom, 
integrity, and unfailing guidance of the late Linda Kelley, 
contracting officer for the ICESat mission. 


^ U.S. Government work not protected by U.S. copyright. 
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Procurement Cycle 

The standard competitive spacecraft procurement at the 
Goddard Space Flight Center (GSFC) takes about 190 
days[l] from releasing the Request for Proposal to Award, 
as shown in Figure 1. Although there were still a few 
minor RSDO bugs to be worked out, the ICESat process 
only took 87 days, from mid-November throng early 
February (including yuletide), about half the standard 
duration. 





Figure 1. Standard vs. ICESat Procurement Time 

The solicitation and evaluation times were shortened 
largely because each of the vendor’s catalog spacecraft 
had already been reviewed in detail for the original RSDO 
core contract award, which meant there was a resident 
team of Goddard experts on-hand, fresh from that 
experience who needed no learning curve and were ready 
to review each ICESat offer for mission specifics. 
Furthermore, the offers were also identically formatted 
which simplified the review. This meant the viewpoint of 
all the players. Offerors and reviewers, was unifonn and 
standard at the outset. Focusing on mission-uniques 
meant the evaluation criteria were few: a prioritized list of 
only the major mission requirements which was easily 
mapped to each vendor’s offer. Lesser factors common to 
all the offers such as propulsion, communication, and 
power needed only to be confirmed as unchanged from the 
core offer and hence, did not need in-depth analysis. 

Paperwork 

Another benefit of the RSDO concept was that the mass of 
paperwork to document die mission was minimal; ICESat 
had only eighteen contract data items, compared with 
cost-type procurements which typically have at least 50 or 
more items. Beyond just technical documentation, the 
fixed-price performance base payment schedule also 
meant less administrative deliverables as well. For 
example, there were no monthly and quarterly cost 
reporting (NASA Form 533s) to regularly review and file. 

Preconceptions 

Over the life of the contract team preconceptions had to 


be consistently overcome. The novelty of the RSDO 
concept had to be repeatedly reinforced among the 
Government team members who were more used to the 
traditional exhaustive contract details of staffing and skill 
levels, task definitions, design minutiae, and other 
material that was just not relevant to a performance-based 
effort. How was less important than did it workl This 
was achieved by keeping die performance issues at the 
fore during weekly telecons and regular management 
briefings. When interesting side paths peripheral to the 
core performance were pursued, no matter how 
fascinating, the team was reminded of the agreed 
performance baseline. 

Unknowns 

The RSDO framework does not handle unknowns like 
schedule uncertainties very well. For example, ICESat 
saw three six-month blocks of schedule delay due to late 
Government-Furnished Equipment (GFE). This could not 
be anticipated in the original request for offer, and so had 
to managed as directed changes each time die schedule 
slipped. It required close coordination with the 
procurement office, the legal office, and the contractor to 
define the change dates with confidence, to establish new 
and repeat tasks for risk reduction, or sometimes to bite 
the bullet and reduce staff during the delay. Each of these 
situations paved new ground in the RSDO arena, but each 
was also successfully addressed in the end (although a 
cost-plus task would have been a lot easier). 

3. Management 

RSDO worked extremely well for managing the ICESat 
implementation. Some of the management lessons- 
leamed noted here are in staffing, furnishing equipment, 
standardization, and milestone management. 

Staffing 

In the area of staffing alone, the performance-based 
contract required less support for monitoring and 
reporting contract performance than does the typical 
Goddard project. Project teams for a mission the size of 
ICESat at Goddard can range in excess of 50 people: the 
core senior staff of four or five, a few administrative 
types, and then specialists for each of the critical 
fimctional and interface areas to oversee the contractor’s 
work. Table 1 shows the typical GSFC staffing versus 
how ICESat was staffed. Due to the performance-based 
milestones, comprehensive oversight of all the contractor 
detailed activities was not necessary, while specialists 
from the Instrumentor staff were selectively retained as- 
needed for consulting and to maintain the Project’s 
insight into mission-critical spacecraft areas such as orbit 
determination, attitude control, and thermal management. 
This support was usually used to support major reviews. 
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Table L Typical Project vs. ICESat Staffing 


TYPICAL PROJECT 

ICESat 

STAFFING 

STAFFING 

Project Manager 

Y 

Deputy Project Manager 


Deputy Project Mgr/Resources 

Y 

Administration 

Y 

Support Specialist 

Y 

Resource Analyst 

Y 

Observatory Manager 

Y 

Systems Engineer 

Y 

Systems Engineering Support 

Y 

Mission Operations 

Y 

Flight Operations 

Y 

Software Systems 

Y 

Launch Vehicle Interface 

Y 

Flight/Quality Assurance 

Y 

Safety 

1 

Financial Manager 

None 

Instrument Manager 

(Instrumentor) 

Command & Data Handling 

As needed 

Communication 

As needed 

EEE Parts 

As needed 

Electrical Power & Distribution 

As needed 

Guidance, Navigation & Control 

As needed 

Integration & Test 

As needed 

rv&V (software) 

As needed 

Propulsion 

As needed 

Structure & Mechanisms 

As needed 

Thermal 

As needed 


Because of the difference between managing fixed-price 
and cost-plus contracts, it was vital to develop and 
maintain a good relationship with the contracting officer 
and the resource (or financial) manager, as well as with 
their counterparts on the contractor side. 

Good communication between key players in the 
organizations keeps management aware of programmatic 
and legal issues before they become problems. Daily talks 
between the spacecraft manager and developer, between 
the systems engineers on both sides, and between 
technical leads, as well as the weekly team meetings, let 
problems get solved at the lowest level before they 
became show-stoppers. 

Furnishing Equipment 

Under performance-based contracting, it is better to never 
provide as Government-Furnished (GF) equipment or 
services, anything the prime could get on its own (ICESat 
had more than 29 GF line items). GF puts the 
Government squarely in the procurement and performance 
chain, with maximum exposure and liability, If the item is 
late, if it fails to perform, if there are access limits due to 


proprietary constraints, if there is missing or inadequate 
documentation, maintenance, repair, updates, whatever, it 
all falls right in you’re the Government’s lap. Even if the 
markup is 200% or more to have the contractor procure 
the item, it is well worth it to get the Project Office out of 
the loop. 

Among the ICESat GFE was the Global Positioning 
System (GPS) receivers and antennas, the spacecraft 
gyroscope, and star trackers on the instrument. Defining 
die interfaces, arranging delivery, assuring performance, 
documenting exceptions, all became major headaches that 
could have been avoided by including the procurement of 
the items in the scope of the delivery order. 

Standardization 

If your office, ftie contracts office, all the support 
organizations, and all the contractors use the same 
versions of word processing, presentation, and 
spreadsheet applications, you are guaranteed to still have 
translation problems that turn math and Greek symbols 
into gibberish. Retain a hard copy of your original text 
and reserve an extra day to confirm and correct the 
receiver’s copy, if needed. The interaction among 
organizations facilitated this for ICESat after it was 
discovered that all die Greek and mathematical symbols in 
the request for offer had been transformed upon receipt 
into smiley faces, pointing hands, and other miscellaneous 
Wingdings, 

If the contractor’s embedded processes for quality 
assurance, anomaly tracking, parts control, etc,, work to 
the RSDO standards, use them instead of your in-house 
process. The efficiency and effectiveness is worth any 
translation or accommodation effort. [2] ICESat used the 
contractor’s File Transfer Protocol (FTP) site to maintain 
the engineering studies and contract data items, so the 
Project Office did not have all the worries on proprietary 
restrictions and international traffic in arms regulation. 
The contractor’s internal anomaly reporting system was 
also evaluated and found to be comparable to Goddard’s, 
so the contractor’s system was used. 

Every Project needs a digital camera - a web-accessible 
picture is worth a thousand meetings. There is no limit to 
the advantage a close-up of a solder joint, broken wire, 
connector, finished assembly, etc. can provide to solve 
problems or punch-up a status briefing. 

Milestones 

This first step in management by milestone is to make sure 
there are clear and unambiguous performance criteria 
defined for each milestone in the request for offer. For 
ICESat, most of the benchmark set defined at delivery 
order award worked well for the life of the contract. 
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Many other milestones were added over the course of time 
to include contract changes and amendments, but some six 
months before launch the requirements for the sign-off 
milestone, on-orbit acceptance, were found to be 
problematic. Because of the four years of trust and 
communication that had grown over the life of the 
delivery order, both Government and contractor text was 
offered up, evaluated, negotiated, and quickly agreed to. 
The milestone was re-defined prior to launch, and served 
well as the defining framework for accepting the 
successful mission after launch (discussed later in this 
paper). 

Do not base performance milestone payment criteria on 
external events beyond the contractor’s control, 
particularly Government-furnished items. Project review 
and approval, or Instrumentor information. When the 
delivery of the science instrument was delayed, the 
Government had to waive some of the criteria for 
Instrument Integration Readiness and pay the milestone 
anyway because our part of the deal was late. 

Never hesitate to withhold a progress payment if a 
performance milestone is not met to your satisfaction[2]; 
the contractor’s corrective action will be incredibly swift. 
It is an excellent tool to ensure actions do not linger but 
get closed-out efficiently. If a payment invoice was 
rejected, the contractor was informed immediately so they 
could start fixing the problem and minimize the delay, 
without waiting for official notice. While infrequent, this 
did happen a few times on ICESat, and was very effective 
when it did occur. 

4. Technical 

RSDO worked fairly well for the technical execution of 
ICESat, but fixed-price is not a friendly environment 
when unknowns are the norm. This issue was most 
evident in the technical arena. The lessons-leamed 
discussed below include Requirements, Integration and 
Test (I&T), and Mission Operations. 

Requirements 

All the contractor provides xmder fixed-price performance 
is a demonstration or test of performance against the 
baseline requirements. So keep these two points in mind: 

• A requirement that is not tested is a goal. 

• There is no recourse if a contractor fails to meet 
a goal. 

Therefore, make sure all requirements are testable, that all 
requirements are tested, and that all tests can be traced 
back to requirements. ICESat had an extensive 
traceability matrix, which the spacecraft insisted upon, to 
accomplish this. 


Under the original RSDO {Rapid I) Statement of Work 
(SOW) there is a task category called “Special Studies” 
(now called “Task Pool” under Rapid IT) which is an 
excellent way to get the contractor to address all the 
technical areas that weren’t included in the SOW in the 
first place. ICESat had more than 25 special studies over 
three years covering topics such as antenna multipath, 
agile spacecraft pointing, payload mass simulator, 
assessment of the reaction wheel sizing, and so on. It is 
crucial to make it very plain right away that the contractor 
does not see “Special Studies” as a way to “get well” for 
schedule or price mistakes m the proposal. ICESat had no 
problem in this area - all technical studies were promptly 
defined and executed. 

The science instrument on ICESat, the Geoscience Laser 
Altimetry System (GLAS), did not have mature interfaces 
and proven procedures at the time of the RSDO spacecraft 
award, so there were many unplanned technical issues 
which took additional time to resolve during the 
spacecraft build. A mature payload package is a better fit 
for RSDO, in order that the Instrumentor avoid throwing 
instniment development problems “over the fence” to the 
spacecraft for solution. Constant vigilance on ICESat 
kept this to a minor and manageable concern. 

Integration and Test 

Fixed-price works great for the definition and 
implementation phases, however, it is very inappropriate 
for I&T. The contractor has to accept fixed price for high 
schedule risk (integrating an unknown instrument) - 
which means any necessary adjustments become very 
costly. Because of this, this phase of the development 
requires more management attention than any other. 

Significant risk reducers for I&T include using: 

• A spacecraft simulator (including engineering 
support) to verify the instrument interface prior 
to flight hardware delivery. 

• An instrument simulator (including engineering 
support) to verify the spacecraft interface prior to 
flight hardware delivery. 

• A master gage/drill template to assure 
mechanical interfacing by both sides of the 
interface. 

For ICESat, mostly due to poor communication among the 
players during requirements definition, the simulators 
never worked to each user’s expectations. Nonetheless, 
every time the limited functionality was exercised between 
the flight hardware and the simulator, an interface 
problem was revealed in time to correct the flight unit. As 
a result, after the flawless mechanical integration shown in 
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Figure 2, the electrical integration successfully completed 
in less than a day. 



Figure 2. ICESat in I&T [3] 

Without simulators, additional months of work are needed 
up front for troubleshooting and corrections after the 
instrument is delivered. It is reasonable to expect as much 
as half of the test procedures, simulations, and Ground 
Support Equipment (GSE) will have errors on first use. 
[ 2 ] 

Fixed-price means there can be tension at the test 
execution level as to who will be the first to call a delay. 
It is best to remove cost and schedule concerns from day- 
to-day decision making among the test conductors as 
much as you possibly can. Maintain a strong continuous 
personal presence throughout System I&T to serve as the 
“honest broker” between organizations and let the as- 
planned I&T flow support the work to be done. [4] For 
ICESat, a log was kept and updated daily by the 
spacecraft and Project managers to account for the day’s 
progress -- noting whether additional time was spent for 
the spacecraft, instrument, or both. Then, when I&T was 
completed, the daily I&T records were racked-up to see if 
the overall schedule performance was within plan, and if 
not, how much price to allocate to the instrument or to the 
spacecraft. 

Gather, plot, and trend data throughout the I&T campaign. 
This will be the performance baseline for analyzing all 
on-orbit anomalies, so the more information the better. 
Make sure to record the test conditions and configuration, 
the procedure versions, and all the test parameters. Many 
quirks and surprises on ICESat became t>pified and 
standardized for flight operations by tracking and 


understanding their occurrence during I&T. 

Mission Operations 

To gain confidence in the mission operations capabilities, 
and to make sure there are not any latent timing problems 
hidden in the software, take the time to run “day-in-the- 
life” and extended duration simulations (e.g. 24/7), with 
the mission operators in support. [4] This way you buzz- 
out the system hardware, software, and staff while there is 
still time to address problems. ICESat ran an 8-day 
exercise that made us much more confident of our ability 
to operate post-launch, including all the clock creeps 
among the star trackers, data bus timing, and instrument 
and spacecraft clocks. 

Allow the mission operations team continuous access to 
all testing activities. [4] This exercises the communication 
link, verifies the procedures, and builds confidence among 
the operations team. Make all the spacecraft and satellite 
test data available to the mission ops team for scenario 
development, procedure tests, etc. Encourage the use of 
the same systems and displays for operations and 
implementation (i.e. “Test it as you fly it, fly it as you test 
it”). ICESat’ s mission operations team was on-line for all 
spacecraft and mission testing, whenever they wanted to 
monitor activities. 

Demonstrate every potential code load during I&T using 
the flight command and telemetry system. [4] This is 
particularly necessary if a unit vendor is absolutely certain 
none of his units has ever needed an on-orbit refresh in the 
entire history of the company. That unit will almost 
certainly be the first one to need a software patch or even 
a complete upload after launch. This happened on ICESat 
when a mature, proven product with extensive flight 
history had performance trouble related to a minor 
mission-unique hardware change that after launch was 
found to affect its performance in certain orbits and 
required a software change to fix it. 

Mission rehearsals with simulated anomalies are a must to 
test the contingency flows and the operations team 
proficiency. [4] These need to be set up and run by very 
experienced teams, particularly teams independent from 
the mission in question. This reveals weak spots in the 
overall functional understanding, and really stresses the 
environment. The ICESat rehearsals ran for days, 24 
hours without stop, with merciless clip-board wielding test 
team members roving among the operators and engineers 
recording performance and deficiencies. 

5. Launch & Early Operations 

In the precise, business-like world of launch vehicles, 
RSDO worked very well. The launch environment is very 
well defined, with a lot of confidence and experience in 
the necessary steps and the execution plan. 
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Launch Support 

The standard RSDO delivery order recommends a pre- 
priced one-month launch slip built in to the contract, 
although that can be tailored to fit the particular mission 
and launch vehicle. For ICESat’s launch on Boeing’s 
workhorse Delta II, one month was sufficient. 

When you hand-over to the laxmch provider, it is no 
longer your system. You have now been relegated to 
“payload” status, and the mission focus is on safety, 
efficiency, countdown, and only then on accommodating 
your needs, whenever possible. Make sure your GSE and 
flight hardware can safely accommodate both momentaiy 
and lengthy power and communication interruptions at the 
pad. Make sure the last known configuration is always 
logged, and at restart automatically run a compliance 
comparison 'with the current configuration. During the 
launch rehearsal, with all the 80-odd consoles fully staffed 
and actively participating in the countdown, the south 
section of Vandenberg lost power and all communication 
and telemetry monitoring was lost. Fortunately, the GSE 
at the launch tower fi-oze pre-flight operations and kept 
telemetry status static until power was restored. 

Once your satellite is lifted on top of the rocket, you loose 
all control of the schedule - it is now up to the rocketeers. 
Include launch support time in your baseUne for the “not- 
needed” activities like battery re-conditioning and general 
cleaning. A back-up detection module on the rocket was 
revealed to have had suspicious performance in earlier 
tests, and a two-week launch hold was declared. This put 
ICESat outside the recommended battery state-of-charge, 
and required reconditioning the batteries over the New 
Year. While it had never been rehearsed, the process of 
toting battery regulators up the tower, connecting coolers, 
and monitoring from the base, went right according to 
plan due to the diligence and expertise of the spacecraft 
contractor. 

On-Orbit Acceptance 

Long before launch, back in the initial request for offer, 
have clear and imambiguous performance requirements 
baselined for mission acceptance. Particularly 
performance requirements that can be clearly and 
unambiguously defined by telemetry (and demonstrated 
during I&T). As discussed earlier, these requirements 
were refined in the last year of the implementation, but 
demonstrating that the expected telemetry would 
dociunent the required parameters was done in mission 
rehearsals, and verified after launch as much as needed to 
satisfy the Government. 


With a customer anxious to take over the mission and a 


contractor eager for the last milestone payment, this is not 
the time for open-ended discussions on differences in 
opinion. 

6. Conclusions/Lessons Learned 

NASA’s RSDO concept works well for missions with 
mature payloads (well-defined interfaces and functions), 
whose management keeps the following points in mind: 

1 . Keep Government-furnished items to the 
minimxim. 

2. Read and memorize lesson Number 1. 

3. Contractors have no mercy. This means your 
statement of work should include all the info or 
data you really need, or think you really need, 
for the life of the contract - you may not get 
anything else. (But don’t go overboard.) 

4. RSDO will shorten the procurement cycle and 
reduce lifetime paperwork, if you know what 
you want to buy. 

5. Changing requirements and loose schedule are 
not good for the fixed-price environment. Hold 
the Instrumentor to strict documentation and 
performance requirements during development. 
The Instrumentor’ s problems are the 
Instrumentor’ s problems. 

6. A performance-based contract requires clear and 
unambiguous milestone payment criteria, which 
the contractor can meet without outside help. 

7. The RSDO “Special Studies” (now called the 
“Task Pool” under Rapid II) are an excellent 
way to analyze and define changes and address 
new situations, as long as the contractor does 
not see them as a way to “get well”. 

8. Integration and test should proceed with the test 
conductors isolated from the schedule and cost 
accounting. Keep track of accountmg separately 
with management, and do a rack-up after testing 
is done. 

9. If you have to delay the spacecraft schedule, 
mission operations activities like day-in-the-life 
and long duration tests are excellent gap fillers. 

• 10. Use the contractor’s internal processes wherever 
possible, as long as they meet the performance 
requirements. 
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